REMARKS 



1. Present Status of Patent Application 

This is a full and timely response to the outstanding non-final Office Action of July 
30, 2009. Claims 1, 10, 19, and 24 have been amended and claims 1, 3, 5-11, 13-14, 
16-19, 21-25, 27, and 29-32 remain pending in the present application. 
Reconsideration and allowance of the application and presently pending claims are 
respectfully requested. 

2. Response to Objection to the Specification 

The Office Action objects to the specification as allegedly failing to provide 
antecedent basis for "a file transfer server having a processor," as recited in claims 1 and 
19. In response, Applicants point to FIG. 1B which shows a host computer having a 
processor 175. The host computer in FIG. 1B represents the host computer 105a and 
105b of FIG. 1A. See lines 11-12 at page 8. Both host computers 105a, 105b show a 
connectdirect server 125a in FIG. 1A, also referred as a "Connect: Direct file transfer 
server 125a" on lines 8-11 at page 7 of Applicant's disclosure. Accordingly, the host 
computer 105a acts as file transfer server as described in Applicant's disclosure. As such, 
"a file transfer server having a processor" language in claims 1 and 19 is clearly supported 
by the present application. Withdrawal of the objection is respectfully requested. 



3. 



Response to Rejections of Claims under 35 U.S.C. 5103 



Claims 1, 3, 5-11, 13-14, 16-19, 21-22, 24-25, 27, and 29-32 have been rejected 
under 35 U.S.C. §1 03(a) as allegedly being unpatentable over Persels (U.S. Patent No. 
7,065,547) in view of Hashem (U.S. Patent No. 7,155,578). 



a. Claim 1 

As provided in independent claim 1 , Applicant claims: 
A file handling system, comprising: 

a terminating file transfer server operable to receive a file transfer 
message from an originating file transfer server along with at least one file, 
the file transfer message including details about the transfer of said at 
least one file including a local user and at least one filename for said at 
least one file, the terminating file transfer server in response to 
receiving the file transfer message, executing an agent; 

the agent operable to read the file transfer message received 
from the originating file transfer server, and direct the transfer of 
said at least one filename and said at least one file associated with 
said at least one filename to a home directory of the terminating file 
transfer server, the home directory associated with the local user in 
accordance with instructions from a configuration file residing in the 
home directory; and 

the configuration file residing in the home directory, and 
operable to instruct the agent to, after saving the at least one file to 
the home directory, transfer said at least one file from the home 
directory to a remote host specified in the configuration file, wherein 
the configuration file comprises a host name and a port name of the 
remote host thereby allowing transfer of said at least one file to the 
remote host without necessitating the remote host being logged on 
the terminating file transfer server. 

(Emphasis added). 

Applicant respectfully submits that independent claim 1 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"the terminating file transfer server in response to receiving the file transfer message, 
executing an agent; the agent operable to read the file transfer message received from 
the originating file transfer server, and direct the transfer of said at least one filename 
and said at least one file associated with said at least one filename to a home directory 
of the terminating file transfer server, the home directory associated with the local user 
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in accordance with instructions from a configuration file residing in the home directory; 
and the configuration file residing in the home directory, and operable to instruct the 
agent to, after saving the at least one file to the home directory, transfer said at least 
one file from the home directory to a remote host specified in the configuration file, 
wherein the configuration file comprises a host name and a port name of the remote 
host thereby allowing transfer of said at least one file to the remote host without 
necessitating the remote host being logged on the terminating file transfer server," as 
emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening . The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24 
(Emphasis added). 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "the terminating file transfer server in response to receiving the 
file transfer message, executing an agent; the agent operable to read the file transfer 
message received from the originating file transfer server, and direct the transfer of said 
at least one filename and said at least one file associated with said at least one 
filename to a home directory of the terminating file transfer server, the home directory 
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associated with the local user in accordance with instructions from a configuration file 
residing in the home directory; and the configuration file residing in the home directory, 
and operable to instruct the agent to, after saving the at least one file to the home 
directory, transfer said at least one file from the home directory to a remote host 
specified in the configuration file, wherein the configuration file comprises a host name 
and a port name of the remote host thereby allowing transfer of said at least one file to 
the remote host without necessitating the remote host being logged on the terminating 
file transfer server," as recited in claim 1 . 

The Office Action contends that Hashem remedies the deficiencies of Persels in 
disclosing the features of claim 1. Hashem describes techniques for transferring files 
from a first location to a second location. Hashem describes that a file may be placed in 
an outbasket at a first location and a process at the first location transfers the file to an 
inbasket at a second location. See Fig. 5. 

For example, Hashem states that a "user will download files when a user needs 
to retrieve a file from another location, i.e., such as the remote entity 80. To perform 
such downloading, the user configures the system of the invention to indicate the 
locations where the files will be downloaded from. That is, the user configures the 
configuration parameters file 66 in the memory portion 60 to provide various 
associations between the various baskets. For example when uploading, a file that is 
placed in the internal outbasket 42 is transferred, based on the configuration 
information, to the external inbasket 87 in the remote entity FTP processing portion 82. 
In a similar manner when downloading or retrieving-a file that is placed in the external 
outbasket 85 in the remote entity FTP processing portion 82 may be configured for 
transfer to the internal inbasket 52, i.e., based on the configuration parameters that are 
stored in the configuration parameters file 66 in the FTP processing portion 10. That is, 
in accordance with one embodiment of the invention, the network interface portion 20 
determines the source of a file upon receipt of a file. Based on the source, the network 
interface portion 20 places the file in an internal inbasket, i.e., based on the parameters 
in the configuration parameters file 66." Cols. 8-9, lines 47-2 (Indentation removed). 
Therefore, an internal inbasket appears to be more akin to a home directory, using the 
language of claim 1, than to a remote host. It is noted that claim 1 requires a file to be 
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received at a terminating file transfer server, transferred and stored in a home directory 
by an agent, and then transferred from the home directory to a remote host as specified 
in a configuration file residing in the home directory. Hashem does not satisfy these 
requirements and does not remedy the deficiencies of Persels . 

On this point, the Office Action asserts that "Hashem automatically download 
files to the destination user without requiring the destination user to login to the terminal 
file server." Page 3. Applicant respectfully disagrees. Rather, Hashem discloses a 
home system 4 having a home FTP processing portion 10 and a remote entity 80 
having a remote entity FTP processing portion 82. See FIG. 1. The home FTP 
processing portion 10 contains an internal outbasket 42 and internal inbasket 52. See 
FIG. 2. The remote entity FTP processing portion 82 contains an external outbasket 85 
and external inbasket 87. See FIG. 4. Accordingly, to transfer a file from home system 
4 to remote entity 80, the file is placed in the internal outbasket 42 of the home system 4 
and then transferred to the external inbasket 87 of the remote entity 80. Likewise, to 
transfer a file from remote entity 80 to home system 4, the file is placed in the external 
outbasket 85 of the remote entity 80 and then transferred to the internal inbasket 52 of 
the home system 4. Hashem does not disclose the further act of transferring the file 
from either the internal inbasket 52 or external inbasket 87 in accordance with a 
configuration file residing in the respective inbasket . 

As such, Persels in view of Hashem fails to teach or suggest at least "the 
terminating file transfer server in response to receiving the file transfer message, 
executing an agent; the agent operable to read the file transfer message received from 
the originating file transfer server, and direct the transfer of said at least one filename 
and said at least one file associated with said at least one filename to a home directory 
of the terminating file transfer server , the home directory associated with the local user 
in accordance with instructions from a configuration file residing in the home directory; 
and the configuration file residing in the home directory, and operable to instruct the 
agent to, after saving the at least one file to the home directory, transfer said at least 
one file from the home directory to a remote host specified in the configuration file, 
wherein the configuration file comprises a host name and a port name of the remote 
host thereby allowing transfer of said at least one file to the remote host without 
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necessitating the remote host being logged on the terminating file transfer server ," as 
recited in claim 1 . (Emphasis added). 

Accordingly, claim 1 is patentable over Persels in view of Hashem, and the 
rejection of claim 1 should be withdrawn. 



b. Claims 3 and 5-9 

For at least the reasons given above, claim 1 is allowable over the cited art of 
record. Since claims 3 and 5-9 depend from and include the features of claim 1 and recite 
additional features, claims 3 and 5-9 are allowable as a matter of law over the cited art of 
record. 



c. Claim 10 

As provided in independent claim 10, Applicant claims: 

A method of handling files on a Connect:Direct server, comprising: 
receiving a file transfer message from an originating file transfer 

server at a terminating file transfer server; 

in response to receiving the file transfer message, executing 

an agent; 

determining, by the agent, a home directory of the terminating 
file transfer server from a local user associated with the file transfer 
message; 

storing at least one file associated with the file transfer 
message in the home directory; 

retrieving, by the agent, a configuration file from the home 
directory, wherein the configuration file comprises a host name and 
a port name of a remote host; and 

transmitting, via the agent, said at least one file responsive to 
the configuration file to the remote host without necessitating the 
remote host being logged on the terminating file transfer server. 

(Emphasis added). 

Applicant respectfully submits that independent claim 10 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"in response to receiving the file transfer message, executing an agent; determining, by 
the agent, a home directory of the terminating file transfer server from a local user 
associated with the file transfer message; storing at least one file associated with the file 



13 



transfer message in the home directory; retrieving, by the agent, a configuration file 
from the home directory, wherein the configuration file comprises a host name and a 
port name of a remote host; and transmitting, via the agent, said at least one file 
responsive to the configuration file to the remote host without necessitating the remote 
host being logged on the terminating file transfer server," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening. The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24. 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "in response to receiving the file transfer message, executing 
an agent; determining, by the agent, a home directory of the terminating file transfer 
server from a local user associated with the file transfer message; storing at least one 
file associated with the file transfer message in the home directory; retrieving, by the 
agent, a configuration file from the home directory, wherein the configuration file 
comprises a host name and a port name of a remote host; and transmitting, via the 
agent, said at least one file responsive to the configuration file to the remote host 
without necessitating the remote host being logged on the terminating file transfer 
server," as recited in claim 10. 
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The Office Action contends that Hashem remedies the deficiencies of Persels in 
disclosing the features of claim 10. Hashem describes techniques for transferring files 
from a first location to a second location. Hashem describes that a file may be placed in 
an outbasket at a first location and a process at the first location transfers the file to an 
inbasket at a second location. See Fig. 5. 

For example, Hashem states that a "user will download files when a user needs 
to retrieve a file from another location, i.e., such as the remote entity 80. To perform 
such downloading, the user configures the system of the invention to indicate the 
locations where the files will be downloaded from. That is, the user configures the 
configuration parameters file 66 in the memory portion 60 to provide various 
associations between the various baskets. For example when uploading, a file that is 
placed in the internal outbasket 42 is transferred, based on the configuration 
information, to the external inbasket 87 in the remote entity FTP processing portion 82. 
In a similar manner when downloading or retrieving--a file that is placed in the external 
outbasket 85 in the remote entity FTP processing portion 82 may be configured for 
transfer to the internal inbasket 52, i.e., based on the configuration parameters that are 
stored in the configuration parameters file 66 in the FTP processing portion 10. That is, 
in accordance with one embodiment of the invention, the network interface portion 20 
determines the source of a file upon receipt of a file. Based on the source, the network 
interface portion 20 places the file in an internal inbasket, i.e., based on the parameters 
in the configuration parameters file 66." Cols. 8-9, lines 47-2 (Indentation removed). 
Therefore, an internal inbasket appears to be more akin to a home directory, using the 
language of claim 10, than to a remote host. It is noted that claim 10 requires a file to 
be received at a terminating file transfer server, transferred and stored in a home 
directory by an agent, and then transferred from the home directory to a remote host as 
specified in a configuration file residing in the home directory. Hashem does not satisfy 
these requirements and does not remedy the deficiencies of Persels. 

On this point, the Office Action asserts that "Hashem automatically download 
files to the destination user without requiring the destination user to login to the terminal 
file server." Page 3. Applicant respectfully disagrees. Rather, Hashem discloses a 
home system 4 having a home FTP processing portion 10 and a remote entity 80 
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having a remote entity FTP processing portion 82. See FIG. 1. The home FTP 
processing portion 10 contains an internal outbasket 42 and internal inbasket 52. See 
FIG. 2. The remote entity FTP processing portion 82 contains an external outbasket 85 
and external inbasket 87. See FIG. 4. Accordingly, to transfer a file from home system 
4 to remote entity 80, the file is placed in the internal outbasket 42 of the home system 4 
and then transferred to the external inbasket 87 of the remote entity 80. Likewise, to 
transfer a file from remote entity 80 to home system 4, the file is placed in the external 
outbasket 85 of the remote entity 80 and then transferred to the internal inbasket 52 of 
the home system 4. Hashem does not disclose the further act of transferring the file 
from either the internal inbasket 52 or external inbasket 87 in accordance with a 
configuration file residing in the respective inbasket. 

As such, Persels in view of Hashem fails to teach or suggest at least "in 
response to receiving the file transfer message, executing an agent; determining, by the 
agent, a home directory of the terminating file transfer server from a local user 
associated with the file transfer message; storing at least one file associated with the file 
transfer message in the home directory; retrieving, by the agent, a configuration file 
from the home directory, wherein the configuration file comprises a host name and a 
port name of a remote host; and transmitting, via the agent, said at least one file 
responsive to the configuration file to the remote host without necessitating the remote 
host being logged on the terminating file transfer server," as recited in claim 10. 

Accordingly, claim 10 is patentable over Persels in view of Hashem, and the 
rejection of claim 10 should be withdrawn. 

d. Claims 11, 13-14, and 16-18 

For at least the reasons given above, claim 10 is allowable over the cited art of 
record. Since claims 11,13-14, and 16-18 depend from and include the features of claim 
10 and recite additional features, claims 11, 13-14, and 16-18 are allowable as a matter of 
law over the cited art of record. 
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As provided in independent claim 19, Applicant claims: 

A ConnectDirect file handling system, comprising: 

a terminating file transfer server; 

an agent; and 

a configuration file; 

the terminating file transfer server launching the agent upon 
receipt of a file transfer message, the file transfer message 
comprising a local username and at least one filename, and the 
agent directing the transfer of and storage of at least one file 
associated with the filename to a home directory of the terminating 
file transfer server associated with the username, the agent reading 
the configuration file, and transferring said at least one file from the 
home directory to a remote host specified by the configuration file 
without necessitating the remote host being logged on the 
terminating file server, wherein the configuration file is operable to 
store a host name and a port number associated with the remote 
host. 

(Emphasis added). 

Applicant respectfully submits that independent claim 19 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"the terminating file transfer server launching the agent upon receipt of a file transfer 
message, the file transfer message comprising a local username and at least one 
filename, and the agent directing the transfer of and storage of at least one file 
associated with the filename to a home directory of the terminating file transfer server 
associated with the username, the agent reading the configuration file, and transferring 
said at least one file from the home directory to a remote host specified by the 
configuration file without necessitating the remote host being logged on the terminating 
file server, wherein the configuration file is operable to store a host name and a port 
number associated with the remote host," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
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message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening. The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24. 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "the terminating file transfer server launching the agent upon 
receipt of a file transfer message, the file transfer message comprising a local 
username and at least one filename, and the agent directing the transfer of and storage 
of at least one file associated with the filename to a home directory of the terminating 
file transfer server associated with the username, the agent reading the configuration 
file, and transferring said at least one file from the home directory to a remote host 
specified by the configuration file without necessitating the remote host being logged on 
the terminating file server, wherein the configuration file is operable to store a host 
name and a port number associated with the remote host," as recited in claim 19. 

The Office Action contends that Hashem remedies the deficiencies of Persels in 
disclosing the features of claim 19. Hashem describes techniques for transferring files 
from a first location to a second location. Hashem describes that a file may be placed in 
an outbasket at a first location and a process at the first location transfers the file to an 
inbasket at a second location. See Fig. 5. 

For example, Hashem states that a "user will download files when a user needs 
to retrieve a file from another location, i.e., such as the remote entity 80. To perform 
such downloading, the user configures the system of the invention to indicate the 
locations where the files will be downloaded from. That is, the user configures the 
configuration parameters file 66 in the memory portion 60 to provide various 
associations between the various baskets. For example when uploading, a file that is 
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placed in the internal outbasket 42 is transferred, based on the configuration 
information, to the external inbasket 87 in the remote entity FTP processing portion 82. 
In a similar manner when downloading or retrieving-a file that is placed in the external 
outbasket 85 in the remote entity FTP processing portion 82 may be configured for 
transfer to the internal inbasket 52, i.e., based on the configuration parameters that are 
stored in the configuration parameters file 66 in the FTP processing portion 10. That is, 
in accordance with one embodiment of the invention, the network interface portion 20 
determines the source of a file upon receipt of a file. Based on the source, the network 
interface portion 20 places the file in an internal inbasket, i.e., based on the parameters 
in the configuration parameters file 66." Cols. 8-9, lines 47-2 (Indentation removed). 
Therefore, an internal inbasket appears to be more akin to a home directory, using the 
language of claim 19, than to a remote host. It is noted that claim 19 requires a file to 
be received at a terminating file server, transferred and stored in a home directory by an 
agent, and then transferred from the home directory to a remote host as specified in a 
configuration file residing in the home directory. Hashem does not satisfy these 
requirements and does not remedy the deficiencies of Persels. 

On this point, the Office Action asserts that "Hashem automatically download 
files to the destination user without requiring the destination user to login to the terminal 
file server." Page 3. Applicant respectfully disagrees. Rather, Hashem discloses a 
home system 4 having a home FTP processing portion 10 and a remote entity 80 
having a remote entity FTP processing portion 82. See FIG. 1. The home FTP 
processing portion 10 contains an internal outbasket 42 and internal inbasket 52. See 
FIG. 2. The remote entity FTP processing portion 82 contains an external outbasket 85 
and external inbasket 87. See FIG. 4. Accordingly, to transfer a file from home system 
4 to remote entity 80, the file is placed in the internal outbasket 42 of the home system 4 
and then transferred to the external inbasket 87 of the remote entity 80. Likewise, to 
transfer a file from remote entity 80 to home system 4, the file is placed in the external 
outbasket 85 of the remote entity 80 and then transferred to the internal inbasket 52 of 
the home system 4. Hashem does not disclose the further act of transferring the file 
from either the internal inbasket 52 or external inbasket 87 in accordance with a 
configuration file residing in the respective inbasket. 
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As such, Persels in view of Hashem fails to teach or suggest at least "the 
terminating file transfer server launching the agent upon receipt of a file transfer 
message, the file transfer message comprising a local username and at least one 
filename, and the agent directing the transfer of and storage of at least one file 
associated with the filename to a home directory of the terminating file transfer server 
associated with the username, the agent reading the configuration file, and transferring 
said at least one file from the home directory to a remote host specified by the 
configuration file without necessitating the remote host being logged on the terminating 
file server, wherein the configuration file is operable to store a host name and a port 
number associated with the remote host," as recited in claim 19. 

Accordingly, claim 19 is patentable over Persels in view of Hashem, and the 
rejection of claim 19 should be withdrawn. 

f. Claims 21 -23 

For at least the reasons given above, claim 19 is allowable over the cited art of 
record. Since claims 21-23 depend from and include the features of claim 19 and recite 
additional features, claims 21-23 are allowable as a matter of law over the cited art of 
record. 

Further, with regard to claim 23, the Office Action states the "renaming of 
downloaded files were well-known in the networking art, as evidenced by Campbell US 
Publication 2005/0086298, Paragraph 254-257, Paragraph 272." Page 4. Applicant 
respectfully traverses the finding and respectfully submits that it has not been 
established that a "the file processor being operable to receive files via the port monitor, 
and assign said at least one filename to said at least one file received, respectively," as 
described in claim 23, is capable of instant and unquestionable demonstration as being 
well-known. 
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g. Claim 24 

As provided in independent claim 24, Applicant claims: 

A computer diskette having a program for handling files on a 
ConnectDirect server, wherein the computer diskette is a physical 
structure executed by a computer and the program is operable to perform: 

receiving a file transfer message from an originating file transfer 
server at a terminating file transfer server; 

in response to receiving the file transfer message, executing 
an agent; 

determining, by the agent, a home directory of the terminating 
file transfer server from a local user associated with the file transfer 
message; 

storing at least one file associated with the file transfer 
message in the home directory; 

retrieving, by the agent, a configuration file from the home 
directory, wherein the configuration file comprises a host name and 
a port name of a remote host; and 

transmitting, via the agent, said at least one file responsive to 
the configuration file to the remote host without necessitating the 
remote host being logged on the terminating file transfer server. 

(Emphasis added). 

Applicant respectfully submits that independent claim 24 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"in response to receiving the file transfer message, executing an agent; determining, by 
the agent, a home directory of the terminating file transfer server from a local user 
associated with the file transfer message; storing at least one file associated with the file 
transfer message in the home directory; retrieving, by the agent, a configuration file 
from the home directory, wherein the configuration file comprises a host name and a 
port name of a remote host; and transmitting, via the agent, said at least one file 
responsive to the configuration file to the remote host without necessitating the remote 
host being logged on the terminating file transfer server," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
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address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening. The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24. 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "in response to receiving the file transfer message, executing 
an agent; determining, by the agent, a home directory of the terminating file transfer 
server from a local user associated with the file transfer message; storing at least one 
file associated with the file transfer message in the home directory; retrieving, by the 
agent, a configuration file from the home directory, wherein the configuration file 
comprises a host name and a port name of a remote host; and transmitting, via the 
agent, said at least one file responsive to the configuration file to the remote host 
without necessitating the remote host being logged on the terminating file transfer 
server," as recited in claim 24. 

The Office Action contends that Hashem remedies the deficiencies of Persels in 
disclosing the features of claim 24. Hashem describes techniques for transferring files 
from a first location to a second location. Hashem describes that a file may be placed in 
an outbasket at a first location and a process at the first location transfers the file to an 
inbasket at a second location. See Fig. 5. 

For example, Hashem states that a "user will download files when a user needs 
to retrieve a file from another location, i.e., such as the remote entity 80. To perform 
such downloading, the user configures the system of the invention to indicate the 
locations where the files will be downloaded from. That is, the user configures the 
configuration parameters file 66 in the memory portion 60 to provide various 
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associations between the various baskets. For example when uploading, a file that is 
placed in the internal outbasket 42 is transferred, based on the configuration 
information, to the external inbasket 87 in the remote entity FTP processing portion 82. 
In a similar manner when downloading or retrieving-a file that is placed in the external 
outbasket 85 in the remote entity FTP processing portion 82 may be configured for 
transfer to the internal inbasket 52, i.e., based on the configuration parameters that are 
stored in the configuration parameters file 66 in the FTP processing portion 10. That is, 
in accordance with one embodiment of the invention, the network interface portion 20 
determines the source of a file upon receipt of a file. Based on the source, the network 
interface portion 20 places the file in an internal inbasket, i.e., based on the parameters 
in the configuration parameters file 66." Cols. 8-9, lines 47-2 (Indentation removed). 
Therefore, an internal inbasket appears to be more akin to a home directory, using the 
language of claim 24, than to a remote host. It is noted that claim 24 requires a file to 
be received at a terminating file transfer server, transferred and stored in a home 
directory by an agent, and then transferred from the home directory to a remote host as 
specified in a configuration file residing in the home directory. Hashem does not satisfy 
these requirements and does not remedy the deficiencies of Persels. 

On this point, the Office Action asserts that "Hashem automatically download 
files to the destination user without requiring the destination user to login to the terminal 
file server." Page 3. Applicant respectfully disagrees. Rather, Hashem discloses a 
home system 4 having a home FTP processing portion 10 and a remote entity 80 
having a remote entity FTP processing portion 82. See FIG. 1. The home FTP 
processing portion 10 contains an internal outbasket 42 and internal inbasket 52. See 
FIG. 2. The remote entity FTP processing portion 82 contains an external outbasket 85 
and external inbasket 87. See FIG. 4. Accordingly, to transfer a file from home system 
4 to remote entity 80, the file is placed in the internal outbasket 42 of the home system 4 
and then transferred to the external inbasket 87 of the remote entity 80. Likewise, to 
transfer a file from remote entity 80 to home system 4, the file is placed in the external 
outbasket 85 of the remote entity 80 and then transferred to the internal inbasket 52 of 
the home system 4. Hashem does not disclose the further act of transferring the file 
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from either the internal inbasket 52 or external inbasket 87 in accordance with a 
configuration file residing in the respective inbasket. 

As such, Persels in view of Hashem fails to teach or suggest at least "in 
response to receiving the file transfer message, executing an agent; determining, by the 
agent, a home directory of the terminating file transfer server from a local user 
associated with the file transfer message; storing at least one file associated with the file 
transfer message in the home directory; retrieving, by the agent, a configuration file 
from the home directory, wherein the configuration file comprises a host name and a 
port name of a remote host; and transmitting, via the agent, said at least one file 
responsive to the configuration file to the remote host without necessitating the remote 
host being logged on the terminating file transfer server," as recited in claim 24. 

Accordingly, claim 24 is patentable over Persels in view of Hashem, and the 
rejection of claim 24 should be withdrawn. 

h. Claims 25. 27. and 29-32 

For at least the reasons given above, claim 24 is allowable over the cited art of 
record. Since claims 25, 27, and 29-32 depend from and include the features of claim 24 
and recite additional features, claims 25, 27, and 29-32 are allowable as a matter of law 
over the cited art of record. 
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CONCLUSION 

Any other statements in the Office Action that are not explicitly addressed herein 
are not intended to be admitted. In addition, any and all findings of inherency are 
traversed as not having been shown to be necessarily present. Furthermore, any and all 
findings of well-known art and official notice, or statements interpreted similarly, should 
not be considered well-known for at least the specific and particular reason that the 
Office Action does not include specific factual findings predicated on sound technical 
and scientific reasoning to support such conclusions. 

For at least the reasons set forth above, Applicant respectfully submits that all 
objections and/or rejections have been traversed, rendered moot, and/or 
accommodated, and that the pending claims are in condition for allowance. Favorable 
reconsideration and allowance of the present application and all pending claims are 
hereby courteously requested. In addition, Applicant reserves the right to address any 
comments made in the Office Action that were not specifically addressed herein. Thus, 
such comments should not be deemed admitted by the Applicant. If, in the opinion of 
the Examiner, a telephonic conference would expedite the examination of this matter, the 
Examiner is invited to call the undersigned agent at (770) 933-9500. 

Respectfully submitted, 

/Charles W. Griqqers/ 

Charles W. Griggers, Reg. No. 47,283 

AT&T Legal Department - TKHR 

Attn: Patent Docketing 
One AT&T Way 
Room 2A-207 
Bedminster, NJ 07921 
Customer No.: 38823 
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